Las Core Web Vitals son tres métricas de rendimiento con las que Google mide la experiencia real de quienes visitan una web: LCP, INP y CLS. Los umbrales «buenos» son LCP ≤ 2,5 s, INP ≤ 200 ms y CLS ≤ 0,1, y lo que cuenta para Google es el dato medido en campo, no en laboratorio. Vigilar primero INP y LCP suele dar el mayor retorno en velocidad percibida y en posicionamiento.
En resumen:
- Mejorar el rendimiento en campo de las métricas LCP e INP ofrece el mayor impacto en la percepción de velocidad y en el posicionamiento en Google.
- Es fundamental priorizar cambios en recursos como imágenes, scripts y estructura para reducir LCP, INP y CLS según los umbrales establecidos.
- Medir en producción con datos de campo y RUM propio es clave, ya que los resultados en laboratorio no garantizan mejoras en la experiencia real.
- La obtención de datos confiables requiere paciencia, ya que los cambios en Core Web Vitals pueden reflejarse oficialmente tras un ciclo de 28 días.
- Optimizar solo en laboratorio puede dar resultados engañosos, por lo que validar en usuarios reales antes y después de intervenir es fundamental para mejoras efectivas.
Tabla de contenidos
- ¿Por qué importan las core web vitals para el SEO y la experiencia de usuario?
- Las métricas: LCP, INP y CLS, umbrales y matices prácticos
- Cómo medir: herramientas y diferencias entre datos de campo y de laboratorio
- Cómo mejorar cada métrica: medidas concretas y priorizadas
- Priorizar intervenciones: auditoría, corrección y monitorización continua
- Checklist rápido para pasar a «bueno» en core web vitals
- Lo que casi nadie cuenta sobre optimizar core web vitals
- Cómo te ayudamos a optimizar tus core web vitals
- Preguntas frecuentes
- Fuentes
¿Por qué importan las core web vitals para el SEO y la experiencia de usuario?
Las Core Web Vitals forman parte de la señal de experiencia de página que Google usa junto a otros factores de relevancia para ordenar resultados. No sustituyen al contenido ni a los enlaces, pero una web lenta o inestable visualmente puede perder posiciones frente a competidores con rendimiento similar en lo demás.
La diferencia entre datos de campo y datos de laboratorio es la base para entender toda la disciplina. Los datos de campo proceden de visitas reales, recogidas por el Chrome User Experience Report (CrUX), y son los que Google usa para calificar una página como buena, mejorable o pobre. Los datos de laboratorio, generados con Lighthouse en condiciones controladas, sirven para diagnosticar y depurar, pero no determinan el estado que ve Search Console.
Más allá del posicionamiento, el rendimiento afecta directamente a la conversión, y un widget de ayuda basado en IA puede mejorar la experiencia y reducir la fricción en el sitio (Konvuno). Una página que tarda en mostrar su contenido principal o que sufre saltos visuales inesperados genera abandono, especialmente en comercio electrónico, donde cada interacción fallida se traduce en un carrito perdido. En blogs y medios, la fricción se nota en tiempo de permanencia y en páginas vistas por sesión. Optimizar las imágenes de una landing page suele ser uno de los primeros arreglos con impacto visible tanto en LCP como en la percepción de velocidad.
Las métricas: LCP, INP y CLS, umbrales y matices prácticos
Cada una de las tres métricas mide un aspecto distinto de la experiencia, y entender qué recurso o interacción cuenta en cada caso evita arreglos que mejoran el número en laboratorio sin cambiar nada en campo.
LCP (Largest Contentful Paint) mide el tiempo que tarda en renderizarse el elemento más grande visible en la ventana inicial: suele ser una imagen de cabecera, un vídeo o un bloque de texto grande. El umbral bueno es ≤ 2,5 segundos, y según Web, una proporción significativa de sitios analizados en CrUX no alcanzan ese umbral, lo que convierte a LCP en la métrica que más intervención técnica suele requerir.
INP (Interaction to Next Paint) sustituyó a First Input Delay (FID) como métrica oficial de interactividad en 2024, según anunció web.dev. A diferencia de FID, que solo medía la primera interacción, INP evalúa la latencia de todas las interacciones a lo largo de la visita, lo que da una foto más fiel del rendimiento percibido. El objetivo práctico es mantenerse en ≤ 200 ms.
CLS (Cumulative Layout Shift) cuantifica los cambios de diseño inesperados, como un banner que empuja el contenido hacia abajo tras cargar. El cálculo agrega la magnitud y la distancia de cada salto durante toda la sesión, y el umbral bueno es ≤ 0,1.
Google evalúa estas tres métricas con el percentil 75 de las visitas durante una ventana móvil de 28 días, según su documentación oficial. Esto significa que una mejora desplegada hoy puede tardar casi un mes en reflejarse de forma estable en Search Console, algo que conviene explicar a cualquier equipo que espere resultados inmediatos.
Cómo medir: herramientas y diferencias entre datos de campo y de laboratorio
Elegir la herramienta correcta depende de si se busca diagnosticar un problema puntual o monitorizar el estado real de una web a lo largo del tiempo.
- PageSpeed Insights combina datos de campo (CrUX, cuando hay tráfico suficiente) y una auditoría de laboratorio con Lighthouse; solo la parte de campo es relevante para el estado que afecta al posicionamiento.
- Search Console, en su informe de Core Web Vitals, agrupa URLs por estado y por métrica problemática, lo que permite priorizar plantillas o secciones enteras en lugar de páginas sueltas.
- CrUX tiene requisitos mínimos de tráfico y de visibilidad pública para incluir una URL; páginas nuevas o de bajo tráfico pueden no aparecer, lo que obliga a instrumentar Real User Monitoring (RUM) propio.
- Lighthouse y las DevTools de Chrome permiten reproducir y depurar un problema en condiciones controladas, aunque sus resultados de laboratorio no deben confundirse con el dato que usa Google para rankear.
Según Vercel, Google considera únicamente los datos de campo para el ranking, mientras que Lighthouse queda como herramienta de diagnóstico. Implementar RUM permite pasar de observar una métrica agregada a identificar el elemento exacto, la ruta o el tipo de usuario que provoca el problema, algo especialmente útil en sitios con componentes de terceros o anuncios.
Cómo mejorar cada métrica: medidas concretas y priorizadas
Las técnicas con mayor retorno, según web.dev, se concentran en unas pocas intervenciones por métrica. El orden siguiente refleja impacto típico sobre coste de implementación.
- Para LCP: identificar el recurso que genera el elemento más grande y priorizarlo desde el HTML con
fetchpriority="high", servir imágenes en formatos modernos y comprimidas, usar una CDN para reducir el tiempo hasta el primer byte (TTFB) y extraer el CSS crítico para evitar bloqueos de render. - Para INP: reducir JavaScript innecesario en la carga inicial, fragmentar tareas largas con técnicas como
requestIdleCallbackoisInputPending, delegar trabajo pesado a web workers y revisar las optimizaciones específicas del framework usado, ya que la hidratación de aplicaciones de página única puede convertir tareas cortas en tareas largas. - Para CLS: definir siempre el ancho y alto de imágenes y vídeos, reservar el espacio exacto donde se insertarán anuncios o widgets dinámicos y evitar animaciones que fuercen un reflujo del documento.
- Medidas que benefician a varias métricas a la vez: usar
preconnectyprefetchpara los orígenes críticos, aplicar renderizado en servidor (SSR), regeneración incremental (ISR) o prerenderizado cuando la plantilla lo permita, y optimizar la carga de fuentes confont-display: swapy precarga de los archivos de fuente usados sobre el pliegue.
Consejo profesional: antes de tocar código, mide con la librería web-vitals en producción durante al menos una semana; así sabrás si el problema real es LCP, INP o CLS antes de invertir tiempo en el candidato equivocado.
Para imágenes concretamente, conviene revisar también la guía práctica sobre optimización de imágenes, ya que el peso visual suele ser el primer cuello de botella tanto en LCP como en CLS cuando faltan dimensiones explícitas.
Priorizar intervenciones: auditoría, corrección y monitorización continua
Una auditoría útil combina tres fuentes: el informe de Core Web Vitals en Search Console para ver qué plantillas fallan, PageSpeed Insights para un diagnóstico técnico puntual y datos de RUM propio para confirmar causas en producción.
- Empezar por las plantillas con más tráfico o más valor de conversión, no por la página más lenta en términos absolutos.
- Priorizar arreglos con coste de implementación bajo y afectación amplia, como definir dimensiones de imágenes, antes que reescrituras de arquitectura.
- Usar RUM para aislar el elemento LCP o la interacción que dispara INP en sesiones reales, en lugar de confiar solo en una auditoría de laboratorio.
- Validar cada cambio esperando al menos un ciclo de 28 días en CrUX antes de concluir que una intervención no funcionó.
Cuando los cuellos de botella están en el front-end, en la infraestructura de servidor o en integraciones de terceros difíciles de aislar, suele llegar el momento de apoyarse en un equipo especializado en desarrollo y diseño web que pueda intervenir sobre la arquitectura, no solo sobre síntomas sueltos.
Checklist rápido para pasar a «bueno» en core web vitals
- Medir primero en campo (CrUX o RUM propio) antes de tocar nada.
- Priorizar el recurso LCP, fragmentar tareas largas para INP y fijar dimensiones para reducir CLS.
- Validar cada cambio con PageSpeed Insights y confirmarlo en Search Console tras el ciclo de 28 días.
- Esperar resultados visibles en semanas para cambios de contenido o imágenes, y en meses para intervenciones de arquitectura o framework.
Lo que casi nadie cuenta sobre optimizar core web vitals
El error más frecuente que vemos en proyectos reales es optimizar solo en laboratorio: un Lighthouse en verde no garantiza nada en campo si el tráfico real llega desde conexiones móviles lentas o dispositivos modestos. La disciplina de medir en producción antes de decidir qué arreglar es la que marca la diferencia entre un informe bonito y una mejora real.
— Santiago
Cómo te ayudamos a optimizar tus core web vitals
Combinamos analítica web con intervenciones de desarrollo y diseño web para auditar tu sitio, instrumentar RUM, priorizar arreglos por impacto y desplegar los cambios, sin dejarte solo con un informe. Si quieres saber por dónde empezar, solicita información sobre nuestros servicios.
Preguntas frecuentes
¿Qué son las core web vitals?
Son tres métricas, LCP, INP y CLS, con las que Google mide la velocidad de carga, la interactividad y la estabilidad visual de una página. Google usa el dato de campo, recogido con CrUX al percentil 75, para decidir si una página está en estado bueno, mejorable o pobre.
¿Para qué se utiliza PageSpeed Insights?
Sirve para ver tanto el dato de campo de una URL, cuando existe tráfico suficiente en CrUX, como una auditoría de laboratorio generada con Lighthouse. El dato de laboratorio ayuda a diagnosticar problemas técnicos, pero según Vercel es el dato de campo el que influye en el ranking.
¿Qué aspecto mide el cumulative layout shift de las core web vitals?
CLS mide los cambios de diseño inesperados que desplazan el contenido mientras la página sigue cargando, como un bloque que empuja el texto hacia abajo. El cálculo agrega la magnitud de cada salto durante toda la visita, y el umbral bueno según Google es ≤ 0,1.
¿Cómo puedo medir el tiempo de carga de una web?
Puedes usar PageSpeed Insights para una medición puntual que combina campo y laboratorio, o instrumentar la librería web-vitals para registrar LCP, INP y CLS directamente desde usuarios reales en producción. Para seguimiento continuo, el informe de Core Web Vitals en Search Console agrupa el estado por plantilla de página.
Fuentes
Recomendaciones
- ¿Cómo Optimizar una Landing page?
- Cómo Optimizar las Imágenes de tu Web
- AMP: Qué son las Accelerated Mobile Pages y por qué son útiles
- ¿Cómo redactar contenido SEO? 11 Secretos + Bonus
